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Abstract 
Without a tel URI parameter to carry an encoding type of Integrated 
Services Digital Network (ISDN) subaddress, interworking between ISDN 
User Part (ISUP) network and a Session Initiation Protocol (SIP) 
network is impossible in some cases. To solve this problem, this 


document specifies a new optional tel URI parameter to carry the 
encoding type of ISDN subaddress. 


Munakata, et al. Informational [Page 1] 


RFC 4715 ISDN for tel URI November 2006 


Table of Contents 


q'ocInbtroductilOns lues d ewAuevRLCIWe S E ERG oe V EE NEUE. 2 
2oecbermbrnoLlogy-454M ume tse crees ear ene See tui e d Ree eq m sed 3 
34 Problém Statement «we penc ERROR SUNG VoS HX EIE Le eR SETS VOS CRY 3 
3), PS LPSESDN Interconnectrion- «iiu uf SUE redo IE ees 3 
922. ISDNSSIPSISDN. Interconnectrion 44e be dl he qe eR v Y eps EE 4 
Ac Redquaeb5ements: cedri aba i etd a odds o ses A olus dE les 5 
5. Parameter Definition i.m ewe] oer Viste ee duris soe. eder ue veas 6 
be SAS ew UE Er RUNE NU M s PR ERU SUR USC SR UE get RU RU EVEURUS E eR ERU RUE E 6 
6.1 Gateway Behavior sn seid ence ect Sere oe Se ee eue YU RE UR dU RE eu S 7 
6.2. SEP Entity Behavior sic ke be toi teed is: a ee x S Uh eee ea e ROUES GS 8 
Te Security-ConsSrderatlonS osse] eid ue eek el ee eomm 8 SiS era hd Sl evs RET E 9 
8. DANA: Coñsiderations 4... Euer er ER UP rU ue OLS: OSE ere eS e e ae 9 
9. (Acknowledgements -serasa ei aena xv ERU. SUE uU E RE SIR Eau er s 9 
JOS.-Reterenegso ho sates Mri I Ae EUN E AER S mh-RUR IN e NUN PETRUS LR areata enaticce: E 12 
LOI. Normative References Lex VERON RO EE UR DNE EE 12 
10.2. Informative: References uv belle Behe VA eeu 12 
1. Introduction 


RFC 3966 [2] defines a tel URI parameter "isub" that is designed to 
carry Integrated Services Digital Network (ISDN) subaddresses. 


In an ISDN User Part (ISUP) message, a Network Service Access Point 
(NSAP) address [6] or a "user specified" address can be carried as an 
ISDN subaddress. The NSAP address accommodates various types of 
address information along with an identifier for the address type and 
its encoding type. 


The "isub" parameter can carry any type of address, but RFC 3966 [2] 
does not define a solution to carry information on a subaddress type 
(whether the subaddress is NSAP or user specific) or an identifier 
for the encoding type used. 


The most commonly used encoding type for the ISDN subaddress is an 
International Alphabet 5 (IA5) [5]. RFC 3966 does state, "ISDN 
subaddresses typically contain IA5 characters but may contain any 
octet value" considering this fact. Nevertheless, IA5 is just one of 
the encoding types among various encoding types used in the NSAP 
address. Therefore, "isub" parameter alone is not sufficient to 
describe ISDN subaddresses, and additional information is needed. 
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Lack of information describing the encoding type of ISDN 
subaddress will make it difficult for an ISDN terminal receiving 
the ISDN subaddress from the SIP network (SIP-ISDN 
Interconnection) to interpret the "isub" parameter value, as a 
gateway may translate it using a wrong encoding type and end up 
with a wrong subaddress value due to inconsistency in the encoding 
type used. It will also make it difficult to recover the original 
ISDN subaddress value when an ISUP message is translated to a SIP 
message and translated back to the ISUP message (ISDN-SIP-ISDN 
Interconnection). As there is no placeholder to carry the 
encoding type in the SIP message, the encoding type information 
that was present in the original ISUP message will be lost, and 
reconstructing the intended ISDN subaddress value is nearly 
impossible. 


To solve the issues presented, this specification defines an "isub- 
encoding" parameter to carry information describing whether the value 
of the "isub" parameter is an NSAP address as well as its encoding 
type. In addition, this document specifies the accommodating values 
to be carried in the "isub" parameter for each encoding type used. 


2. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [1]. 

3. Problem Statement 
Without a tel URI parameter to carry an encoding type of ISDN 
subaddress, the problems described in Sections 3.1. and 3.2. might be 


observed. 


3.1. SIP-ISDN Interconnection 


The diagrams in Figure 1 show an issue that will be observed when 
interworking between SIP network and ISDN network with an ISDN 
subaddress. When SIP equipment sends a request with an "isub" 
parameter to address an ISDN terminal behind Private Branch Exchange 
(PBX), the encoding type of the ISDN subaddress currently cannot be 
specified. Therefore, gateway sitting between the SIP network and 
ISDN network cannot translate the value of "isub" into an ISUP 
Initial Address Message (IAM) properly as the encoding type 
information of the ISDN subaddress is missing. 
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ISDN Terminal 


4----- + 
i Bob 
SIP Network «---|--- > ISDN 12345 
| 4----- + 
SIP Equipment | 
4----- * 4----- + +----+ 4----- + | 4----- + 
| Alice |------- >| Proxy |----- >| ew |----- >| PBX |----- >|Carol 
4+----- + 4+----- + 4+----+ 4----- + 4+----- + 
| 4----- + 
|--->|David| 
4+----- + 
Alice ae i IUS "I ai 
| mwe | | "p | 
|------------ > | INVITE | | | | 
| — >| ram | | 
| | |----->| servP| | 
----> SETUP 
EM E 


Figure 1: SIP-ISDN Interconnection 
INVITE tel:+17005554141; isub=12345 SIP/2.0 


Note: SETUP is an ISDN message used between ISDN switch and 
ISDN end terminal. 


3.2. ISDN-SIP-ISDN Interconnection 


The diagrams in Figure 2 show an issue that will be observed when 
interworking messages with an ISDN subaddress between two ISDN 
networks that traverses through SIP networks. When an ISDN terminal 
sends a message that contains an ISDN subaddress along with its 
encoding type information, Gateway 1 translates the subaddress into 
an "isub" parameter in a SIP message. However, its encoding type 
information is dropped because there is no placeholder for the 
encoding type in the SIP message. When Gateway 2 receives the 
"isub", it cannot translate the value of the "isub" parameter back 
into the IAM message properly because the encoding type information 
of the ISDN subaddress is missing. 
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ISDN Terminal 


4----- + 
--->| Bob 
ISDN <---|--- > SIP Network  «---|--- > ISDN 12345 
| 4----- 4 
ISDN Terminal | 
4----- + 4----- 4 4----- 4 4----- 4 4----- + | 4----- + 
Alice|----- >| ewi |---->|Proxy|---->| Gw2 |---->| PBx |----- >|Carol 
+----- + +----- + +----- + +----- + +----- + +----- + 
| 4----- + 
|--->|David| 
+----- + 
Alice Switch  GW1 Proxy GW2 Switch PBX Bob 
sep N | | 
E >| IAM | | | | | 
| |---->| INVITE | | | | | 
| MEL >| mem | | | 
| || |---------- >| mam | | | 
———--»|SETUP 
| MEM | ux alae | 
| | | | | | 
| | | | | | 


Figure 2: ISDN-SIP-ISDN Interconnection 
INVITE tel:+17005554141;isub=12345 SIP/2.0 
4. Requirements 


The followings are requirements for a solution to carry an ISDN 
subaddress along with information of subaddress encoding type. 


Req 1: When the "isub" parameter is present but no "isub-encoding" 
parameter is present in a tel URI, the encoding of the ISDN 
subaddress in the original message MUST be assumed to be IA5 
(AFI-0x50). 


Req 2: When using the "isub" parameters in tel URIs, the encoding 
SHOULD be specified by using the optional "isub-encoding" 
parameter unless the encoding of the ISDN subaddress is IA5 
(AFI-0x50). 
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Parameter Definition 


The parameter defined in this document is represented as a tel URI 
parameter, which describes the encoding type information of the ISDN 


subaddress. It is an optional parameter to tel URI to accommodate 
some of the information lacking in the "isub" parameter defined in 
RFC 3966 [2]. The ABNF [3] syntax is as follows. 


isub-encoding isub-encoding-tag "=" isub-encoding-value 
isub-encoding-tag "isub-encoding" 
isub-encoding-value = "nsap-ia5" / "nsap-bcd" / "nsap" / token 


The semantics of these "isub-encoding" values are described below: 


nsap-ia5: Indication that the "isub" parameter value needs to be 
encoded using IA5 (AFI=0x50) when translated to an ISUP 
message. 


nsap-bcd: Indication that the "isub" parameter value needs to be 
encoded using Binary Coded Decimal (BCD) (AFI-0x48) when 
translated to an ISUP message. 


nsap: Indication that the "isub" parameter value needs to be 
encoded using the encoding type defined in ISO 8348 [6] 
other than IA5 (AFI-0x50) or BCD (AFI-0x48). 


Note: Q.931 [7] defines a "user specified" subaddress type, but 
this document does not specify any behavior or value for 
"user specified" subaddress type. Therefore, the "user 
specified" subaddress is beyond the scope of this document. 


An example of the syntax of the "isub-encoding" parameter (in a small 
fragment of a SIP [4] message) is given below: 


INVITE tel:+17005554141; isub=12345; isub-encoding=nsap-ia5 SIP/2.0 
To: «tel:-«17005554141;isub-12345;isub-encoding-nsap-ia5» 
From: "Bob"<sip:bob@biloxi.example.com>; tag=1928301774 


Usage 


It is anticipated that a tel URI parameter defined in this document 
will be used along with an "isub" parameter defined in RFC 3966 [2] 
when interworking between an ISUP network and a SIP network. The URI 
parameter defined here is an optional parameter to the tel URI and is 
useful only when it’s accompanying the "isub" parameter. 
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An ISDN subaddress information element carried in the ISUP message 
consists of a 3-octet header followed by either an NSAP address or a 


user-specified address. The NSAP address consists of an Initial 
Domain Part (IDP) (Authority and Format Identifier (AFI) and 
conditionally Initial Domain Identifier (IDI)) that identifies an 


encoding type of the subaddress, and a Domain Specific Part (DSP) 
that represents the subaddress value itself. 


To find out more about the ISDN subaddress information element and 
the NSAP address including definition of AFI, IDI, IDP, and DSP, 
please refer to Appendices A and B. 


If the "isub-encoding" is absent, and a message is interpreted by an 
entity on the SIP network, the entity compliant to this specification 
MUST assume that the original ISDN subaddress in an ISUP message was 
an NSAP address with an encoding type of IA5 (AFI-0x50), of which the 
DSP value was translated and set to the "isub" parameter value, and 
MUST handle the message accordingly. 


If the "isub-encoding" is absent, and the message is handled by a 
gateway translating the SIP message to ISUP message, the gateway 
compliant to this specification MUST encode the value in the "isub" 
parameter using IA5 (AFI-0x50) and set the encoded value into the DSP 
part of the NSAP address when translating the message into an ISUP 
message. 


If the value of "isub-encoding" is set to "nsap", the encoding type 
(AFI) is assumed to be in the first two characters of the "isub" 
parameter in hexadecimal represented as US-ASCII characters 0-9 and 
A-F. 


If the ISDN subaddress is not an NSAP address, the entity translating 
the message SHOULD treat the message as if neither the "isub- 
encoding" nor the "isub" parameters existed, unless it has a prior 
knowledge of the encoding method used. 


When an entity that is not compliant to this specification handles 
the message with the "isub-encoding" parameter, it would simply 
ignore the parameter and its value. 


6.1. Gateway Behavior 
A gateway compliant to this specification that receives a message/ 
signal from an ISDN network containing an ISDN subaddress MUST check 


the encoding used for the subaddress and MUST follow the procedures 
given below. 
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If the ISDN subaddress is an NSAP address encoded using IA5 
(AFI-0x50), the entity MAY set the "isub-encoding" parameter to 
the value "nsap-ia5" and set the DSP value of the NSAP address as 
the value for the "isub" parameter using characters permitted for 
the "isub" parameter as specified in RFC 3966 [2] or omit the 
"isub-encoding" parameter. 


If the ISDN subaddress is an NSAP address encoded using BCD 
(AFI-0x48), the entity MUST set the "isub-encoding" parameter to 
the value "nsap-bcd" and set the decoded DSP value of the NSAP 
address as the value for the "isub" parameter in US-ASCII 
characters using numbers. 


Note: Each semi-octet should be translated into numbers (e.g. 
01011001 would be translated as 5 and 9). 


If the ISDN subaddress is an NSAP address but is not encoded using 
either IA5 (AFI-0x50) or BCD (AFI-0x48), the entity translating 
the message MUST set the "isub-encoding" parameter to the value 
"nsap" and the entire NSAP address as the value for the "isub" 
parameter in hexadecimal represented as US-ASCII characters (0-9 
and A-F). 


If the ISDN subaddress is not an NSAP address, the entity 
translating the message SHOULD NOT generate any "isub-encoding" or 
"isub" parameters, unless it has a private agreement with the 
recipient about what to do in this case. 


6.2. SIP Entity Behavior 


An entity compliant to this specification setting an "isub" parameter 
MUST follow the procedures given below. 


If the ISDN subaddress is an NSAP address encoded using IA5 
(AFI-0x50), the entity MAY set the "isub-encoding" to "nsap-ia5". 
The "isub" parameter value MUST NOT exceed 19 characters. The 
characters used MUST follow the syntax defined for the "isub" 
parameter as specified in RFC 3966 [2]. 


If the ISDN subaddress is an NSAP address encoded using BCD 
(AFI=0x48), the entity MUST set the "isub-encoding" to "nsap-bcd". 
The "isub" parameter value MUST NOT exceed 38 US-ASCII characters 
(numbers). 
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7. 


If the ISDN subaddress is an NSAP address encoded using an 
encoding type other than IA5 (AFI-0x50) or BCD (AFI-0x48), the 
entity MUST set the "isub-encoding" to "nsap". The "isub" 
parameter value MUST NOT exceed 40 US-ASCII characters and it MUST 
be in hexadecimal represented as US-ASCII characters (0-9 and A- 
F). The first two characters of the "isub" parameter MUST be the 
encoding type (AFI) in this case. 


Security Considerations 


The parameter defined here adds no new security considerations to 
those discussed in RFC 3966 [2]. 


IANA Considerations 
This document requires no action by IANA. 


Further information on a registry for tel parameters is covered in 
[8]. 
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Appendix A. Structure of an ISDN Subaddress Information Element 


The structure of an ISDN subaddress information element in ISUP 
messages is defined in Q.931 [7] as follows. 


Bits 
8 7 6 5 4 3 2 1 Octets 

t----- q----------------------------------------- + 

[^n ae 1 1 0 0 0 o | 1 
T----- Pee SSeS See SoS eee Le + 

| Length of called party subaddress contents | 2 
Hmc Pes ss8 54S S S583 Se5 Ss sss Seas assesss= + 

| 1 | Subaddress type | o/e | 0 0 o | 3 
+----- Po SSS esl e SSeS Se SSeS Se Se eS SSS eee SSS + 

| MEC. 

Subaddress information 

| | 

: E a ca E i max. 23 
Figure 3: Structure of an ISDN Subaddress Information Element 


Although the length varies, the maximum length of an ISDN subaddress 
information element shown in the figure above is 23 octets. The 
first 3 octets are the header. The rest of the octets comprise the 
subaddress information that is either an NSAP address or a "user 
Specified" address. 


The 1st octet is a called party subaddress information element 
identifier that identifies that this information element is a called 
party subaddress. The 2nd octet represents the length of called 
party subaddress contents. 


The 5th to 7th bits of the 3rd octet identify the type of subaddress. 
This field is set to 00 0 when the subaddress is an NSAP address. 
It is set to 0 1 0 when the subaddress is "user specified". 


The 4th bit of the 3rd octet is an odd/even indicator. The odd/even 
indicator is used when the type of subaddress is "user specified" 
with the encoding type of BCD, to enable an entity to pad the missing 
bits (last 4 bits of the subaddress information) when the number of 
digits composing the subaddress is odd. 


Note: When interworking with SIP, it is recommended not to 
translate the padding bits to "isub" parameter. 
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Appendix B. Structure of NSAP Addresses 


In ISUP messages, the ISDN subaddress is generally represented as an 
NSAP address. The NSAP address is defined as follows in ISO 8348 


[6]. 
The NSAP address consists of an Initial Domain Part (IDP) and a 
Domain Specific Part (DSP). The IDP consists of two fields, an 
Authority and Format Identifier (AFI) and an Initial Domain 
Identifier (IDI). The maximum length of an NSAP address is 20 
octets. 

qo Sse eae ase aa NSAP Address ------------------ > 

4-------------------------------------------------- t 

I DP 

ir EENES lela DSP 

| AFI IDI | | 

4-------------------------------------------------- t 

0 1 k Pes IOCEEES 0. max. 20 


Figure 4: Structure of NSAP Addresses 


The AFI value is 2 hexadecimal digits (00-FF), and it identifies the 
IDI format and the DSP syntax. 


The IDI value when present is represented as decimal digits, and it 
identifies a network addressing domain or authority responsible for 
allocating values of the DSP. The length of IDI varies and depends 
on the value of AFI. 


The typical encoding type of the ISDN subaddress, IA5, is identified 
as AFI-0x50. When the AFI value is 0x50, the length of IDI is zero; 
therefore, the length of IDP is 2 digits (1 octet). In this case, 
the DSP value is a subaddress encoded by IA5, and its maximum length 
is 19 octets. The length of IDI is also zero when the encoding type 
is BCD (AFI-0x48). The NSAP address for when the AFI value is set to 
either 0x50 or 0x48 is shown below. As shown, DSP starts from the 
2nd octet of the NSAP address. 


q4-----------2-------2-------------2------2------------- t 
| IDP | | 
I DSP | 
| AFI | | 
q4-----------2------2-------2-------2------2------------- t 
0 1 ewe SOCBDOLS. asa max. 20 


Figure 5 Structure of NSAP Addresses (AFI-0x50 or AFI-0x48) 
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